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nteractive programming 
languages are on the move 
again, thanks to the busi- 
ness community’s need and 
enthusiasm for an understandable 
computer language. The much trum- 
peted price/performance improve- 
ments in hardware, coupled with 
inflation-driven increases in personnel 
costs, are giving new life and growth 
to interactive programming languages. 

The economic benefits of interactive 
computing .are increasingly evident, 
effecting a bright future for this 
17-year-old innovation. It yields sig- 
nificant gains in personnel productiv- 
ity since results can be obtained 
quickly. - 

The improved economics that apply 
to increased programmer productivity 
using interactive computing also apply 
to increased programmer productivity 
using a language designed for interac- 
tion. Research shows APL (A Pro- 
gramming Language) gives a huge in- 
crease — 300% to 500% — in program- 
ming productivity at some price in run 
time efficiency. This efficiency “pen- 
alty” is becoming increasingly less ex- 
pensive. 

APL usage is increasing at a rapid 
rate because of its inherent productiv- 
ity benefits. Hence, a review of the his- 
tory of APL and its application to busi- 
ness analysis will interest many DP 
professionals. 


Motivation for Notation 


In the late 1950s, Kenneth Iverson, 
then an applied mathematician at Har- 
vard University, had an academic in- 
terest in various algorithmic processes 
such as methods of arranging data into 


ascending order, new ways to calculate 
Eigenvectors and procedures (manual 
or computer) for running and manag- 
ing order/shipping/billing systems. 

One of Iverson's nagging problems 
was how to communicate his new ideas 
efficiently to others. The most obvious 
possibility was our native language, 
but experts in most technical disci- 
plines know very well that even En- 
glish (which seems better than most 
other languages for this purpose) can 
become cumbersome and confusing 
when used to describe detailed, ab- 
stract concepts. 

Many systems designers have experi- 
enced this difficulty when writing spe- 
cifications for a computer application 
that some other group will code. When 
we attempt to run the completed sys- 
tem, we find the finished product is far 
different from that which the original 
analyst thought was specified. 

In order to assure total understand- 
ing, one must employ great detail — so 
much so that preliminary specifica- 
tions are often much larger than the re- 
sulting program. 

Because uf the limitations of English, 
Iverson considered other means of 
communications. He was aware of the 
then-developing computer program- 
ming languages, but dismissed their 
use because none supported array (ta- 
ble) computations directly. Further, he 
felt that storage allocation statements 
(such as DIMENSION, DATA DIVI- 
SION and similar conventions) were 
roadblocks to exposition and compre- 
hension in the people-to-people com- 
munication of information. 

Iverson also recognized the inade- 
quacies of conventional mathematical 
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notation. For example, the symbol “x” 
has been used to mean ordinary scalar 
multiplication and matrix multiplica- 
tion and to represent “and” for 
Boolean mathematics. The pi symbol 
means both 3.14159 and cumulative 
multiplication. 

The traditional approach taken by 
authors to represent their ideas (when 
conventional notation runs out) is to 
fabricate their own extensions. The re- 
sult of this practice is a virtual Tower 
of Babel in mathematics literature. 
Much effort is wasted in applied texts 
by explaining local notational conven- 
tions. 

Iverson recognized that conventional 
mathematical notation was the best 
starting point to solve this problem. 
Since he was interested in a broad vari- 
ety of quantitative problems, he set out 
to develop one notation covering them 
all. 

This effort led to a comprehensive 
notation which Iverson felt was ade- 
quate for describing algorithmic proc- 
esses, with no bias toward any particu- 
lar application area. 

Iverson's book, A Programming Lan- 
guage (Wiley, 1962), set forth the 
author’s notation as an Esperanto for 
quantitative expression. In that same 
year Iverson joined IBM’s Research 
Center in Yorktown Heights, N.Y. 
There, he and a few devotees conti- 
nued to investigate the adequacy of his 
notation for solving a variety of prob- 
lems. 

These studies were called formal 
descriptions; an expert selected classical 
problems from his own field, such as 
fluid mechanics, computer architecture 
or accounting, and described these 
“textbook” problems in Iverson’s nota- 
tion. He then supplied data and manu- 
ally worked through the steps to see if 
the results were as expected, if the 
statement of the problem was unambi- 
guous and if the entire process was 
“comfortable.” 


The Implementation 


To eliminate the hand calculation re- 
quired, Iverson commissioned an im- 
plementation of his notation on a com- 
puter. In the fall of 1965, this imple- 
mentation was completed and put into 
use. 

It soon became apparent to many that 
the implementation had potential be- 
yond the limited research environment 
for which it was originally designed. 
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REVENUES<10000 12500 25000 


EXPENSES+ 5500 


7125 15000 


Figure 1 





REVENUES 
10000 12500 25000 

EXPENSES 
9900 7125 15000 


Figure 2 





REVENUES-EXPENSES 


4500 5375 10000 


REVENUES+EXPENSES 
1.818181818 1.754385965 1.666666667 
EX PENSES+REVENUES 


0.55 0.57 0.6 


Figure 3 





+/REVENUES 


47500 


Figure 4 





+\REVENUES 
10000 22500 47500 
+\ EXPENSES 
9500 12625 27625 


Figure 5 
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As part of selling IBM management on 
the merits of promoting Iversons 
computer-assisted notation, the group 
chose the acronym APL to describe it. 
Since IBM's language policy was 
firmly centered on Cobol, Fortran and 
PL/I at the time, the appeal to promote 
APL was unsuccessful. 

Meanwhile, the availability of APL at 
the Yorktown Heights Research Cen- 
ter was attractive to the research staff. 
Many people within IBM learned APL 
and used it daily in their work. Word 
of this use spread throughout IBM by 
informal channels. 

By 1974, APL had become the most 
widely used interactive system within 
IBM. Interestingly, most of this APL 
use was for commercial applications. 


Led by this internal growth, APL be- 
gan to leak out. Prior to unbundling, 
APL was available free to outside orga- 
nizations. Universities explored it, and 
time-sharing companies seeking inno- 
vations began to offer it. Today APL is 
available on many modern computers, 
and more than 30 time-sharing compa- 
nies provide APL service as well. 

Reacting to this acceptance in the 
marketplace, IBM has gradually given 
APL an increasingly important official 
status. The current primary APL offer- 
ing from IBM is VSAPL. 

In spite of the fact that APL’s origins 
are in research, its dominant use today 
is for commercial data processing. 
How could a system conceived by 
mathematicians, highly symbolic in 








+\REVENUES-EXPENSES 
4500 9875 19875 


Figure 6 


OREVENUES 


Figure 7 


(+/REVENUES )+pREVENUES 


15833.33333 


Figure 8 


TABLE+2 3pREVENUES, EXPENSES 


Figure 9 


TABLE 


10000 12500 25000 


5500 


7125 15000 


Figure 10 


TABLE4TABLE,[2]+/L2]TABLE 


TABLE 


10000 12500 25000 47500 


5500 


7125 15000 27625 


Figure 11 


+/CL1]TABLE 

15500 19625 40000 75125 
-/L1]TABLE 

4500 5375 10000 19875 


Figure 12 





nature and lacking official sanction be- 
come so popular? We can only suspect 
it is because of its merit and highly fa- 
vorable experience by users. 

If ubiquitous DP terms like DASD, 
JCL and Ebcdic can be briefly ignored, 
the goal of involvement with comput- 
ing returns to consciousness. Most 
business people are concerned with the 
timely and accurate acquisition, reten- 


tion, computation, retrieval and dis- 
play of business information. 

The APL language, along with a re- 
port formatter and an APL-oriented 
file system, can be used very effec- 
tively for business and financial analy- 
ses and computations. 


APL Calculations 


One of the major reasons why Iver- 


son didn’t base his Harvard work on 
existing computer programming lan- 
guages was because they generally 
lacked built-in array (table) handling 
features. Mathematicians tend to use 
the term “matrix algebra” to describe 
this activity; business people view it as 
performing calculations on lists or ta- 
bles of values, such as revenues and 
expense data for a number of time pe- 
riods. 

Examinations will show that table- 
oriented calculations comprise a sur- 
prisingly large part of business and fi- 
nancially oriented analyses. Examples 
in APL are shown in Figure 1. These 
lists (or vectors) can be displayed by 
simply typing their names, as in Figure 
2 


Simple arithmetic operations can be 
performed on the data without having 
to resort to loops, structured program- 
ming or data base management (Figure 
3). Accumulations can also be obtained 
very simply (Figure 4), and even run- 
ning totals are “primitive” operations 
(Figure 5). 

Thus cash flows can be obtained as 
shown in Figure 6. This operation re- 
ports on the number of data items in a 
list (Figure 7) and the average revenue 
is computed by the equation shown in 
Figure 8. 

Our revenues and expenses figures 
can be put together into a two- 


dimensional table (Figure 9). Here we | 


catenated (,) revenues and expenses to- 
gether (a list with six items), then re- 
shaped (p) those six items into a table 
with two rows and three columns (Fig- 
ure 10). 

For display purposes, it may be desir- 
able to catenate a column of totals to 
the table, as shown in Figure 11. Here, 
we re stating over which dimension we 
should sum, since TABLE has more 
than one dimension. Naturally, Figure 
12 also works. 

We can catenate the gross profits as 
another row of TABLE as shown in 
Figure 13. Calculating taxes as .48 of 
gross profits and catenating another 
row is shown in Figure 14. Note that 
this display is mysteriously spread out. 
So far, we haven’t been concerned 
with how APL displays its results — it 
obtained the right answers, but not 
necessarily in the desired format. 

Before we address that, let’s complete 
the table to include net profits (Figure 
15. The data is now computed for a 
simple corporate operating statement, 


but most managers would not accept 
these results without annotation such 
as title, names for the various rows and 
columns and other formatting fea- 
tures. 


Formatting Features 


When APL was implemented on a 
computer, the language did not have 
commercial report-formatting features 
— we lived with what APL chose to 
print or went through mental contor- 
tions to bend the data into acceptable 
form. APL's utility for commercial ap- 
plications would have been diminished 
had its developers ignored this impor- 
tant aspect of computing. 

A variety of formatting “primitives” 
have been developed for APL. One of 
the more popular schemes was devel- 
oped by Scientific Time Sharing Corp. 
(STSC) and has Fortran’s flavor. To 
format the integer table in Figure 15 
into three columns eight characters 
wide and one column 12 characters 
wide, STSC’s formatter works as 
shown in Figure 16. 

But even here APL implementors 
have provided features desirable in 
commercial reporting, such as floating 
currency symbols (Figure 17). Of 
course, the popular picture phrase is 
provided also (Figure 18). 

Figure 19 formats a list of values in a 
field 15 wide, with commas every third 
position, two trailing decimal digits 
and negative numbers in parentheses. 
It prints NONE wherever the data 
value is zero. The stars in the last row 
indicate the number was too long to fit 
in the field provided. 

Formatting numeric results is only 
part of the job in report preparation. 
Another significant aspect is sur- 
rounding the data with meaningful ti- 
tles and annotation. The fundamentals 
of character handling in APL are quite 
simple, as Figure 20 demonstrates. 

That statement finds the occurrence 
of the first blank in the list of charac- 
ters. A command like the one in Figure 
21 drops the first 10 characters and 
leaves the rest to print. 

Now we have a program that accepts 
a list of revenues and a list of expenses, 
and prepares a completed report. 
CENTER, ROWNAMES and COL- 
NAMES are prepared programs which 
make titling easier (Figure 22). 


Voluminous Data 
A frustrating “feature” of early APL 





TABLE*TABLE,L1)-/LIJTABLE 


TABLE 


10000 12500 25000 47500 


9500 
4500 


7125 15000. 27625 
5375 10000 19875 


Figure 13 





TABLE+*TABLE,(1].48xTABLE[3;] 


TABLE 
10000 12500 25000 47500 
5500 7125 15000 21625 
4500 5375 10000 19875 
2160 2580 4800 9540 
Figure 14 
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TABLE<TABLE,(1J1-/CL1IIJTABLEL3 4;] 


TABLE 
10000 12500 
9500 7125 
4500 9375 
2160 2580 
2340 2795 


25000 47500 
15000 27625 
10000 19875 
4800 9540 
9200 10335 


Figure 15 
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implementations was the inability to 
access more than a handful of data. 
This was partly because implementa- 
tion was originally intended to serve 
modest scientific needs and partly be- 
cause APL was implemented with a 
swapping scheme that didn’t mix well 
with a virtual machine architecture. As 
with formatting, user needs dictated 
that in order to survive, APL had to be 
able to handle more data than the 
roughly 32K bytes provided in the 
original version. 

The problem of dealing with large 
amounts of data in APL can be ap- 
proached in four different ways. The 
first is to ignore the problem. This sim- 
ply does not work. 

While there are facilities for copying 
data from one “workspace” to another, 
these are purposely implemented to re- 
quire manual intervention to prevent 
overloading the swapping mechanism 
of the system. 


The second approach, adopted in 
some APL installations, is to modify 
the system to allow COPY commands 
to be executed under program control. 
The commands are typically stored as 
character arrays and executed by trick- 
ing the system to think they are key- 
board inputs. 

Because APL was originally imple- 
mented assuming infrequent, manual 
use of the facility, processing bogged 
down with even moderate use of the 
automated variant. 

The third approach — also a popular 
one — is to employ the virtual memory 
by simply increasing the workspace 
size to a few million bytes. From an 
APL purist’s vantage point, this is an 
elegant approach — no additional lan- 
guage features have to be conjured up. 

Virtual storage is not free, however; 
in the case of APL, its acceptance is its 
own undoing. Imagine performing 
some array operation on two large ar- 





ILLI! 
10000 12500 
5500 7125 
4500 5375 
2160 2580 
2340 2795 





OFMT (TABLE) 


25000 
15000 
10000 
4800 
5200 


Figure 16 


'3CI8,CP<$>F13.2! 


10,000 


3900 
4,500 
2160 
2,340 


12,500 


7,125 
S50 15 
2,580 
25:7 OD 


25,000 
15,000 
10,000 


4,800 
55.200 


Figure 17 


47500 
276295 
19875 

9540 
10335 


UFMT (TABLE) 
$47,500.00 
$27,625.00 
$19,875.00 

$9,540.00 
$10,335.00 





'G<PHONE (999) 999-9999>! 
OFMT (9144286910 3016578220) 


PHONE (914) 428-6910 
PHONE (301) 657-8220 


Figure 18 
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'CBR< 


NONE >M<(>N<)>Q< >F15.2! 


(98,765.00) 


0.12 
NONE 
123.45 
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10 


TITLE! 


Figure 19 
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Figure 20 


UFMT (XX) 


TITLE*'OPERATING STATEMENT ' 
oTITLE 





rays that just happen to reside in dif- 
ferent pages. The system must page 
for nearly every operation. 

A clever virtual operating system 
would compensate for that by keeping 
the relevant pages in main memory. If 
you have 10 or 50 or 100 APL users 
connected, all doing large array opera- 
tions simultaneously, the available 
main storage will be exhausted. 

Further, this simplistic approach of 
using virtual storage does not address 
the need to share data among users. In 
effect, it precludes the possibility of 
doing real-time processing employing 
shared data bases. 

IBM’s more recent APL offerings, 
APLSV and VSAPL, provide an ele- 
gant interface mechanism called 
“shared variables.” Through this inter- 
face, the APL user can access data 
stored by other APL users as well as 
data stored by alien (non-APL) proc- 
essors. 

For example, one can get at OS data 
sets or embody any of the commer- 
cially available data base management 
systems in his APL code. This tech- 
nique can be applied when APL appli- 
cations are written to perform interac- 
tive information retrieval on data 
stored by the production systems. 

The problems with selling this ap- 
proach to APL people is that most of 
them are not DP professionals in the 
classic sense. They are reluctant to deal 
machine-dependent data representa- 
tions. The typical APL user knows 
there is a difference between numeric 
data and character data, but packed- 
decimal, half-word integer, double- 
precision floating-point and bit storage 
are alien concepts. As we've seen in the 
previous examples, you don’t need to 
know them to get the business results 
you need. 

The fourth approach is to provide a 
file system harmonious with APL phi- 
losophy — that is, not concerning the 
user with internal representation but 
being more sparing of computer re- 
sources than faking the manual com- 
mands or resorting solely to virtual 
workspaces. This solution is used by 
many major APL time-sharing vendors 
and several computer manufacturers; 
it can also be implemented via the 
shared variable mechanism of today’s 
IBM APL offerings. 

Many of these APL file systems differ 
in external appearance and in certain 
features, but the general approach is 


the same for almost all. 

Experience has shown changing from 
one version to another is not a major 
problem. 


APL File Systems: An Example 


Imagine being responsible for keep- 
ing the medical records of some 5,000 
patients. When a patient comes in for a 
visit, a standard set of 13 tests is done, 
and all 13 test results are kept for fu- 
ture analysis and study. 

Although the same tests are made for 
each patient at each visit, some pa- 
tients may accumulate many more 
visits than others. Records are kept 
only for the most recent 100 visits of 
each patient. 

A likely structure for holding this 
data (if it could fit in the workspace) 
would be a three-dimensional array of 
patients by visits and by test results. In 
the file we’re going to make, the com- 
ponent or record numbering will cor- 
respond to the first dimension of this 
hypothetical three-dimensional array, 
and each component will consist of a 
given patient’s data. Each component 
will be a matrix whose row dimension 
is the number of visits so far, and there 
will be 13 columns for the 13 test re- 
sults. 

First we have to create and name a file 
(Figure 23). The operation DFCREATE 
is used to create the file. The left argu- 
ment is the name of the file and the 
right argument is the file tie number or 
the number that logically connects the 
user with the desired data file. 

There is no permanent connection 
between a file name and a file tie num- 
ber. A file can be tied to whatever 
number you choose in any session. 

O FSIZE helps the user determine 
physical attributes of a particular file. 
Its argument is an active file tie num- 
ber. The result is a four-element vector 
holding (1) the lowest numbered com- 
ponent in the file, (2) the number of 
the next available component in the 
file, (3) the amount of space currently 
used in the file and (4) the total space 
available in the file (Figure 24). 

The lowest component in our file is 1, 
but the next available component is 
also 1. This an indication that the file is 
empty, which is certainly what we'd 


expect for a file into which we have 


put nothing. The third element is zero, 
again indicating an empty file. The last 
element is 100864, which is the nomi- 
nal byte capacity for this file. 





10¥TITLE 
STATEMENT 


Figure 21 





V REV REPORT EXP 
[1] a LEFT ARG IS REVENUES, RIGHT IS EXPENSES. 
[2] ARRAY<(2,pREV)pREV,EXP a MAKE TABLE 
3] ARRAY+ARRAY,[2]+/[2] ARRAY a SUM ACROSS AND CATENATE 
C4] ARRAY+ARRAY,(1]-/{1] ARRAY a ROW 3: GROSS PROFIT 
[5] ARRAY+ARRAY,[1] 0.48xARRAY[3;] a ROW 4: TAXES 
L6] ARRAY+ARRAY,[1]-/[1] ARRAY[3 4 ;] a ROW 5: NET 
[7] LINES+10 ROWNAMES '/REVENUES/EXPENSES/GROSS/TAXES/NET' 
[8] FORMAT+«'10A1,3(CI8,X3),P<$>CI10! 
[9] FORMAT CENTER ‘OPERATING STATEMENT! 


AJROSE 2 APR 77 


[10] LEE 
[11] FORMAT COLNAMES '/LINE ITEM/DIV. A/DIV. B/DIV. C/TOTAL' 
[12] ? 
[13] FORMAT (FMT (LINES;ARRAY ) 
V 


10000 12500 25000 REPORT 5500 7125 15000 
OPERATING STATEMENT 








LINE ITEM DIV. A DIV. B DIV.C TOTAL 
REVENUES 10,000 12,500 25,000 $47,500 
EXPENSES 5,500 T125 15,000 $27,625 
GROSS 4,500 55375 10,000 $19,875 
TAXES 2,160 2,580 4,800 $9,540 
NET 2,340 2,795 5,200 $10,335 

Figure 22 

'MEDICAL' UFCREATE 76 
Figure 23 
OFSIZE 76 


1 1 0 100864 


Figure 24 





"MEDICAL 28000000! ỌFCREATE 76 


Figure 25 
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28000000 LFRESIZE 76 


Figure 26 
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P1 


9 313 4 2 1 4 3 3 8 4 8 19 
P2 


23 5 1 4 8 9 10 20 3 4 5 12 5 


Figure 27 


P1 UFAPPEND 76 
UFSIZE 76 


1 2 6304 28002368 


Figure 28 


P2 DFAPPEND 76 © OFSIZE 76 
1 3 6304 28002368 


Figure 29 


P2<()FREAD 7/6 2 9 P1+UFREAD 76 1 


Figure 30 


V R«TOTVISITS N;COUNTER 
C1] a N IS THE FILE TIE NUMBER 
[2] R+0 © COUNTER+(DFSIZE N)[1]-1 
C3] LOOP:COUNTER«COUNTER+1 9 +0 IF COUNTER=(OFSIZE N)(2] 
C4] R+R+itpOFREAD N,COUNTER © +LOOP 
v 
TOTVISITS 76 


Figure 31 


V NEWPATIENT N 


C1] a N IS THE FILE TIE NUMBER 
[2] 'THIS IS PATIENT ';(DFSIZE N)L2] 
L3] (0 13p0) UFAPPEND N 

V 


Figure 32 


V P NEWVISIT N;DATA 

[1] a P IS PATIENT NUMBER, N IS FILE TIE NUMBER. 

[2] >OK IF (P2>(OFSIZE N)C1J))AP<(OFSIZE N)[2] 

[3] 'NO SUCH PATIENT NUMBER' 9O +0 

[4] OK:'ENTER 13 VALUES! 

C5] +UPDATE IF 13=pDATA+<,Q 

[6] 'INVALID INPUT: ';:pDATA;' VALUES ENTERED' 9 +0 

[7] UPDATE:DATA+(QFREAD N,P),(1)] DATA 9 DATA OFREPLACE N,P 
y 


Figure 33 
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Our file obviously doesn’t have the 
capacity to hold all the data we intend 
for it. This space can be provided in 
two ways. If we had created the file in 
Figure 25, then it would have had the 
required capacity (computed from 4 
bytes per integer to be stored, times 
5000 patients, times 100 rows, times 
13 columns), plus 4% overhead. 

Alternatively, we could have used 

CiIFRESIZE (Figure 26). The right 
argument is the file tie number, and the 
left argument is the amount of space to 
be reserved for the file. 

Let's now begin to store some data in 
the file. We'll use the variables P1 and 
P2 which contain data on-hand for 
two patients (Figure 27). 

We are simulating Patient 1 with two 
visits and Patient 2 with one visit. In 
Figure 28, we put Patient 1 on the file, 
using O FAPPEND. 

O FAPPEND puts the value of its 
left argument as a new component at 
the end of the file designated in the 
right argument. The lowest compo- 
nent is still number 1, but the next 
available component is now number 2. 
The “diamond” character acts as a 
statement separator. 

Continuing, we add Patient 2, as 
shown in Figure 29. Note that the 
space used (third element of the result 
of DO FSIZE took a big jump after 
the first O FAPPEND, but didn’t in- 
crease after the second. This is the re- 
sult of internal trade-offs for storage 
and time efficiency. 

When you make your first append, 
the system reserves 6,304 bytes of 
storage, keeps it handy and won't re- 
serve any more until you've used it all 


up. 
To read information from a file, 
OQ FREAD is used (Figure 30). This 


brings into the active workspace an 


image of the file component. Although 
in this example we read the values 
back into the same variables from 
which they came, it is not necessary. 
For example, we could have entered 
P2OFREAD 76 1 and PI1OFREAD 76 
2, which would interchange the data 
for patients 1 and 2 in the workspace 
(but not in the file). 

Figure 31 shows a simple function to 
find the total number of visits by all 
patients (that is, the total number of 
rows in the file). 

Here are two more examples of pro- 
grams that are obvious necessities: (1) 
establishing a new patient in the file by 


methods slightly more sophisticated 
than that done previously and (2) ad- 
ding the results of a subsequent visit to 
any individual patient's data already in 
the file. 

The first is handled by the defined 
function NEWPATIENT (Figure 32). 
This function simply appends an 
empty matrix for the new patient and 
prints the patient number that was as- 
signed. 

Figure 33 demonstrates a defined 
function for recording the data 
gathered on a patient’s visit. The new 
file function, FREPLACE, on line 7, re- 
places the P-th file component with 
new data from the workspace. In our 
case, it’s the catenation of what was in 
the component with another row, DA- 
TA, on the bottom. 


Unique Relation 


There doesn’t have to be any relation 
between what is being replaced and 
what it is being replaced by, although 
in this example case there happened to 
be. The requirement that only the most 
recent 100 visits are to be kept in the 
file can be satisfied simply by chang- 
ing the second statement on line 7 to 
read as in Figure 34. 

Having written functions to enroll a 
new patient and enter the data from a 
visit, we now turn to programs for get- 
ting selected data from the file. Com- 
plete data on each patient can be ob- 
tained by reading his component. Fig- 
ure 35 shows a function for obtaining 
a table consisting of the data from a set 
of patient’s most recent visits. Figure 
36 shows how more general search and 
retrieval tasks can be performed. 

We could continue with this example, 
but the point has been made. The APL 
file consists of a sequence of records or 
components, each of which is an arbi- 
trary APL data object. 

There need be no preordained pattern 
of shapes, sizes or data types for the 
file organization. Records can be re- 
placed by larger records or by other 
data types. The user does not have to 
be concerned about the internal repre- 
sentation of data. 

There are also functions to drop rec- 
ords from the low end or the high end 
of the file, thereby facilitating first in/- 
first out (Fifo) and last in/first out 
(Lifo) architectures. Since the organi- 
zation is arbitratry, the user can build 
keyed indexed systems easily by using 
tixed components (or even a second 
file) as the keys. 
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Figure 34 
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Figure 35 
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Figure 36 
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A Business Computation Notation 


It is clear that APL has inherent merit 
in algorithmic expression. Augmented 
by a report formatting system and a 
file system, it satisfies the require- 
menis of commercial data processing. 

However, a controversy still lingers 
over symbolic notations (of which 
APL is an example) vs. English-like 
programming languages such as Co- 
bol. The controversy centers around 
the trade-off between clumsy interac- 
tive programming structures, such as 
Cobol’s DIVISION structure and un- 
forgiving syntax analyzer, and API's 
strange-looking notation. 

Many DP professionals believe the 
demand for increased programmer 
productivity will combine with mod- 
ern executives’ demands for a clear, 
concise interactive programming lan- 
guage to create an explosive demand 


for APL. As more top business man- 


agers gain and use formal quantitative 
business skills, APL will move into the 


executive suite in a way that conven- 
tional languages cannot. 

APL is a way to think and express 
oneself quantitatively, rather than an- 
other structured language to convert a 
series of calculation steps to machine- 
readable form. As a new means of 
thinking, APL will provide huge pro- 
ductivity increases throughout many 
Organizations. 

An interesting exercise is to solve the 
problems presented in this discussion 
with Fortran, Cobol or Basic, then 
compare the amount of code required 
with the APL solutions represented. 
You will find that the vast increase in 
code beyond that required for an APL 
solution illustrates the inherent “peo- 
ple productivity” of the APL language. 

The increase in APL use, already ex- 
perienced by firms such as IBM and 
Xerox, will soon spread to much of the 
rest of the business community. Why? 
Because as a tool for business and fi- 
nancial analysis and planning, APL 
simply has no peer. 


